question: ‏Is it valid to have two successive UTF-16 codepoints where the first is contained in [HIGH_SURROGATE_BEGIN, HIGH_SURROGATE_END) and the second is not contained in [LOW_SURROGATE_BEGIN, LOW_SURROGATE_END)? If not, then I think we are missing a parse error here for this case.

AFAIK, it's considered as error for UTF-16.
https://en.wikipedia.org/wiki/UTF-16#Code_points_from_U+010000_to_U+10FFFF
Since the ranges for the high surrogates (0xD800–0xDBFF), low surrogates (0xDC00–0xDFFF), and valid BMP characters (0x0000–0xD7FF, 0xE000–0xFFFF) are disjoint, it is not possible for a surrogate to match a BMP character, or for two adjacent code units to look like a legal surrogate pair. This simplifies searches a great deal.

https://en.wikipedia.org/wiki/UTF-16#U+D800_to_U+DFFF_(surrogates)

It is possible to unambiguously encode an unpaired surrogate (a high surrogate code point not followed by a low one, or a low one not preceded by a high one) in the format of UTF-16 by using a code unit equal to the code point. The result is not valid UTF-16, but the majority of UTF-16 encoder and decoder implementations do this when translating between encodings.

OK, so if I understand correctly, we want logic that is something like:

hex_val = parse_unicode_hex(stream);
if (is_high_surrogate(hex_val)) {
    auto hex_val_low = parse_unicode_hex(stream);
    if (is_low_surrogate(hex_val_low)) {
        // valid surrogate pair, decode
    } else {
        // invalid surrogate pair, parse error
        // I think this case is missing
        return {bytes, parse_error};
    }
} else {
   // non-surrogate pair, decode as normal
}

But I think the parse error in the case that we have a pair where the first is a surrogate pair and the second is not handled. Except that maybe this is deliberate per:

The result is not valid UTF-16, but the majority of UTF-16 encoder and decoder implementations do this when translating between encodings.

So you're just "carrying on" and letting an invalid character appear in the output stream. Is that right?

If so, maybe

suggestion: Add a comment explaining this parsing behaviour.

That's right.
added a comment at the place where this is skipped, not thrown as error.